Data communication networks may be generalized into at least two types: asynchronous and synchronous. Performance characteristics and transmission latencies in synchronous networks are understood, and in many cases predictable. However, many asynchronous networks can be easier and less expensive to deploy and maintain than typical synchronous networks. In light of the convergence of disparate networks, there arises a need to provide methods and systems for interconnecting asynchronous networks with synchronous networks. Asynchronous networks typically operate under well known protocols, including by not limited to, the Transmission Control Protocol (TCP), Internet Protocol (IP), User Datagram Protocol (UDP) to name but a few. A well known synchronous network approach includes time division multiplexing (TDM), which can allocate particular data channels to predetermined time slots.
One very particular application for interconnecting asynchronous and synchronous systems is the transmission of “real-time” traffic, for example voice data. Conventional voice data examples will now be described.
Conventionally, voice data remains separate from network data traffic. In particular, many enterprises may have a data network connecting a variety of workstations as well as a public branch exchange (PBX) for voice data. As data networks proliferate, it is becoming an increasingly desirable goal to integrate transmission of voice and data onto a converged network “backbone.”
Transmitting data over a synchronous network, such as a time division multiplex (TDM) voice system, typically includes framing data. Frames are allocated portions of bandwidth, usually formed according to a time division multiplexing scheme. TDM arrangements may be less flexible than asynchronous approaches because time slots are allocated to particular streams. Thus once a time slot is allocated, it may not be used for another data stream until it has be re-allocated.
Another way to provide real time data can be transmitting such data over an asynchronous network. For example, voice data may be transmitted with a “voice over packet” system Voice over packet can take advantage of existing network structures. Further, as noted above, networks (including the Internet) continue to grow in size and in bandwidth, reducing the cost and/or increasing the feasibility of such systems.
Many networks can be “connectionless” networks. Connectionless networks can provide multiple possible paths between source and destination. Consequently, in some cases, voice transmitted over such networks may be more reliable as voice data can reach a destination even if some of the network nodes are not operational.
Data networks may take a variety of forms. As noted above, a data network may be a connectionless network, including the Internet. Further, a network may include portions that are overlaid and/or integrate connection-oriented legs. Such systems include Internet protocol (IP) over asynchronous transfer mode (ATM) and multiprotocol label switching (MPLS), or similar switching systems.
One possible drawback to transmitting voice data over connectionless networks, or networks having connectionless portions, can be the potential for different portions of the same voice stream arriving out of sequence. For example, a stream of voice data is typically broken down into samples and transmitted in a particular sequence over a network. However, while such samples can be transmitted in order, because packets may travel along different legs of a network, a sample may arrive out of order. Still further, it is possible for packets to be dropped. Thus, a voice sample may never arrive at a desired destination.
In voice over packet arrangements, voice data needs to be reassembled in the same order that it was transmitted with minimal latency. This can be difficult to achieve with many conventional approaches.
Various proposals for implementing voice over packet have been proposed. One general approach is the idea of a network “gateway.” A network gateway can provide access to a network (such as the Internet) for a variety of conventional voice data sources (voice channels). As but one example, a network gateway can be an IP gateway that integrates a PBX with an IP network. In such an arrangement, users may make telephone calls that appear entirely conventional, but are in fact being transmitted over a data network.
One drawback associated with voice over packet can be the latency introduced by such approaches. Various sources may contribute to latency. A transmitting source introduces some delay in placing the voice into packet form. Typically the voice data can be digitized and/or compressed and then placed in packet form. Transmission of the voice over packet can also introduce latency. Routing from node to node, or along a switching path, can consume additional time. Finally, a receiving destination can introduce delay. Voice data can be extracted from a packet and then transmitted along an appropriate voice channel. Such packet processing can be conventionally accomplished on a channel-by-channel basis. That is, single packets may contain the voice data for a single voice channel.
According to one conventional approach, a network voice packet can be forwarded to a destination according to conventional protocols, such as the Real-time Transport Protocol (RTP). A destination can include conventional network hardware, such as a network interface card, which can receive the packet. A general purpose processor can then extract voice data within the packet (including any decoding/decompressing) and then play the voice data over sound card, or the like. Such computation steps can contribute significantly to latency.
According to another conventional approach, a network can include a network phone (such as an “IP Phone”). A network phone can have its own network address, and include packet processing and voice data processing hardware.
One conventional way to decrease latency is with more complex routers. In particular, some routers may be capable of giving particular packets precedence over others. As but one example, some packet headers can include a “type of service” or “quality of service” field. A network voice packet can be given higher precedence than other packets, thereby reducing latency when compared to other packets. A drawback to such approaches is that all routers/switches in the network must have such an advanced processing capability, and thus can be expensive to implement. Consequently, such an approach may be better suited for enterprise wide area networks (WANs), instead of a larger network structure such as the Internet.
Another approach can essentially reserve a route for a voice packet flow. One such approach is the Resource ReserVation Protocol (RSVP). RSVP, like the precedence approach noted above, can rely on more complex routers and thus be an expensive solution.
While the approaches described above can reduce latency for voice packet data, such approaches may be difficult and/or expensive to implement. Further, it is still desirable to reduce latency even more. Thus, further ways of decreasing latency in network voice packets could a valuable contribution to voice over packet.
While conventional packet forwarding of voice over a packet may provide adequate results, this may not always be the case. To help improve the processing of time dependent data, including voice data, a number of protocols have been proposed. One such protocol is the Real-Time Transport Protocol (RTP). An RTP header can provide sequence and timestamp information than may help assemble voice data once it has been received.
Another concern that may arise out of voice over packet is different possible voice data formats. Some formats may require different processing than others. Further, the processing of one voice format type may take longer and/or require more resources than other voice formats. For example, systems may have different vocoding techniques for digitizing speech for transmission in a packet, resulting in different size payloads representing speed samples.
Further, different packet formats may represent different numbers of data sources. As but two of the many possible examples, “multiplexed” packets, can contain data from multiple sources, while “simplex” packets, may contain voice data form a single source. With the advent of multiplexed and simplex packets, systems may have to be capable of accommodating both types of payloads.
Voice data can present a challenge to voice over packet systems. In particular, it can be a complex task to extract voice samples from a packet, and then arrangement such samples for playback. Multiplexed voice data may present a greater challenge in that multiple voice samples have to be extracted from a single packet payload.
Voice over packet systems are typically “asynchronous” in that voice data samples may arrive at varying time intervals and/or in varying order. This is in contrast to conventional “synchronous” voice systems, such as TDM systems, that reserve time slots for particular voice channels. An important issue arriving out of systems that seek to transfer voice data from an asynchronous system to a synchronous system can be variable network delay in voice data arriving from an asynchronous system (jitter).
Of course, it is understood that voice data represent but one of the many applications for interconnecting asynchronous and synchronous systems. A system for accounting for network jitter could have various other applications that transmit data from an asynchronous network to a synchronous network. Such alternative applications include, but are not limited to other non-voice data applications, including but not limited to video data and various other computing applications.
In light of the above, it would be desirable to arrive at a method that can receive data from an asynchronous network, and store such data for synchronous access by a synchronous network. Such a method could address various drawbacks to conventional approaches, and could be particularly valuable in voice over packet applications.